貝老闆:今天新進工程師 King 到位,加上原本的 AI 實習生大眼子,雙核開發!
AI 實習生: 修改完成~儲存~修改完成~儲存~
小可:結果兩個人都在 Replit 線上編同一檔,King 存檔,AI 又覆蓋,最後上線變成「合體失敗版」。
貝老闆:我只看到一堆「 Auto‑saved 」訊息……
King:大眼子動作太快我來不及 Review,我以前都自己來,到底要怎麼跟大眼子合作!??
(電話撥出)
好威:恭喜解鎖「同步地獄」。線上共編不是不要,而是別在 main。照我口令:Fork → PR → Review Checklist → 受保護分支 + CODEOWNERS。讓改動走大馬路,不要鑽小巷子撞車。
1)主倉庫 read‑only:AI 實習生 先 Fork,所有變更走 Pull Request,讓 King 和小可 Review
2)每支 PR 附 變更清單/風險/回滾方式,Review 未通過不得合併。
3)開啟 Branch Protection:禁 force‑push、要求 1~2 人審核、要求 CI 綠燈、阻擋直接改 main
。
4)設定 CODEOWNERS:核心路徑必須由指定人審,避免「誰都可以動核心」。
1️⃣ Fork/PR 為什麼比線上共編安全? 直接在 Replit 同檔共編,就像兩個設計師在同一張海報上同時貼圖,存檔互蓋很正常。Fork 讓每個人有私人分支空間,PR 把差異攤開在陽光下:誰改了什麼、為什麼改、與主線差多少。PR 留痕跡、可對照、能回滾;線上共編很難追溯責任,更難做「一次只改一件事」。
2️⃣ Branch Protection 是交通號誌。 受保護分支(通常 main
/release/*
)強制大家在紅綠燈下過馬路:要求通過 CI、至少一位 Reviewer 核可、禁止直接推送與 rebase 改史,必要時要求 線性歷史。這些規則不是麻煩,而是把「壞變更」擋在門外,讓事故在 PR 階段就被攔下。
3️⃣ CODEOWNERS 確保「對的人」看關鍵改動。 在 CODEOWNERS
檔將資料庫、金流、權限等敏感路徑綁定到資深工程師或系統 owner,GitHub 會自動把他們加進 Reviewer。這能避免新人或 AI 誤動核心,讓懂脈絡的人站在門口把關。對跨時區團隊也能縮短「找誰看」的時間。
4️⃣ Review Checklist+小 CI,讓品質自動化。 為 PR 附上固定清單:功能目標、風險、測試方式、可回滾點(如 feature flag 或 revert 指令)。再配一個輕量 CI(lint、單元測試、build、smoke),變更一送出就自動驗證。人看意圖,機器看細節,兩者互補,降低「看漏」風險。
CODEOWNERS
(用途:指定審核權)
# 根目錄默認由核心組負責
* @core-team
# 金流與權限必須資深審
/payments/** @king @senior-dev
/auth/** @security-lead
PR 範本(用途:統一說明格式)
# 目的
-
# 變更
-
# 風險與影響
-
# 測試與驗收步驟
-
# 回滾方式
- Feature flag / revert PR / hotfix
Branch Protection 建議(摘要):
lint
、test
、build
;Block direct push;Disallow force‑push;Require linear history(可選)。A.流程是護欄,不是阻力。 新人與 AI 實習生的產能像渦輪,但主線需要護欄才不會翻車。Fork/PR/受保護分支讓改動「排隊進場」,速度不一定慢,因為少了回溯成本與爭吵時間。
B.把審核變成模板與機器任務。 人會累、會漏,Checklist 與 CI 不會。把「要問的話」寫進 PR 模板,把「該檢的細節」寫給 CI,Reviewer 就能把注意力放在架構與風險,而不是字串逗號。
C.明確擁有權,降低協作摩擦。 CODEOWNERS
把路徑對到人,任何人(含 AI)想動核心,都會自動通知負責人。這比群組裡吼「誰動了資料庫?」有效率多了。
兩句精煉重點:
1)你的主線目前有哪些風險路徑需要 CODEOWNERS
?
2)把今天的專案加上「最小 CI」與 PR 模板,實測一次 Fork→PR 流程卡在哪裡?
小作業 Prompt:
依下列專案條件(Node 18/Next.js/GitHub),請生成:
CODEOWNERS
、.github/pull_request_template.md
與lint+test
的 GitHub Actions。並輸出在 GitHub 的 Branch Protection 設定步驟(要求 1 reviewer、3 個狀態檢查、禁止直接推main
)。